Java-Revolution auf dem Content-Markt?

Dieser Vorschlag wurde im Februar beim Java Community Process eingereicht, wobei die JCR-Expertengruppe unter Leitung des CTO von Day Software David Nuescheler hofft, in der zweiten Jahreshälfte 2003 einen endgültigen Entwurf vorlegen zu können.

JCR bildet einen weiteren Schritt in der unausweichlichen Entwicklung der CMS (Content Management Systems) weg von den proprietären Ungetümen der Vergangenheit hin zu flexibleren, interoperablen Architekturen, die eine herstellerunabhängige Zusammenarbeit verschiedener Layer des CMS-Stacks ermöglichen. Dies bedeutet Vorteile für Unternehmen, die ihre eigenen CMS-Lösungen erstellen, für die Entwickler dieser Lösungen und – trotz möglicher Anfangsschwierigkeiten mancher Unternehmen – für die CMS-Branche im Allgemeinen.

Das JCR würde einen neuen Layer im CMS-Stack darstellen: zwischen den CMS- oder Portal-Anwendungen und dem zugrunde liegenden Content-Storage-Tool (wie z.B. ein RDBMS, das Dateisystem, ein LDAP-Server, XML oder andere Systeme zur Datenspeicherung). Das JCR soll dabei auf API-Ebene eine ähnliche Rolle übernehmen, wie sie der Standard-SQL in einem RDBMS zukommt. Nach Ansicht von Nuescheler würde das JCR „eine standardisierte, Implementierungs-unabhängige Möglichkeit für einen bidirektionalen Content-Zugriff auf granularer Ebene innerhalb eines Content Repository“ darstellen. Das bedeutet, dass die CMS-Tools, statt direkt auf die Speicher zuzugreifen, die Zugriffsverfahren des JCR nutzen würden, die wiederum mit der zugrunde liegenden Speicher-Technologie interagieren. Die Spezifikation enthält außerdem Verfahren für Versionskontrolle, Volltextsuche- und filtering, Ereignisüberwachung, Namensräume sowie für die Handhabung von Mehrfachzugriffen und Transaktionen.

Durch die Bereitstellung eines Abstraktions-Layers ermöglicht das JCR eine deutlich größere Flexibilität bei der Auswahl und Zusammenstellung von CMS-Produkten und Content-Storage-Tools – Nuescheler spricht in diesem Zusammenhang von „Swappability“. Darüber hinaus könnte auf diese Weise die Integration zwischen den verschiedenen Komponenten einer verteilten Anwendung erheblich vereinfacht werden. So könnte ein einzelnes Repository mehrere Clients betreuen, wenn diese die gleiche API verwenden. Umgekehrt könnte eine einzelne Anwendung die Ressourcen unterschiedlicher Repositories nutzen. „Anbieter von Anwendungen, die auf zugrunde liegenden Repositories basieren, müssen nicht länger Dutzende separater Content Repositories mit ihren eigenen APIs integrieren oder proprietäre Abstraktions-APIs einsetzen“, so Nuescheler. Auch die Integration mit vorhandenen Technologien würde vereinfacht, da diese außerhalb der eigentlichen CMS-Anwendung stattfinden könnte, mithilfe einer selbst geschriebenen oder gekauften JCR-Bridge.

Entscheidend ist hierbei, dass der Zugriff auf den Content vom Speichern des Contents getrennt wird, so dass sowohl die Anwendung als auch das Speicherverfahren verändert werden können, ohne sich gegenseitig zu beeinträchtigen.